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The Laboratory for Applications of Remote Sensing at 
Purdue University has developed an earth resources data pro- 
cessing system which is being used by both LARS personnel and 
remote terminal users in part to determine the value of the 
system for training/ technology transfer/ and data proces- 
sing. The results of Purdue's participation in this pro- 
ject are documented in this report. The facility has been 
used at seven separate sites and demonstrated to be a cost 
effe^ctive system for training personnel- and technology trans- 
fer as well as meeting many data processing needs. 
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I . INTRODUCTION 


The Laboratory for Applications of Remote Sensing (LARS) 
at Purdue University has developed an Earth Resources Data 
Processing System which is being used by both LARS personnel 
and remote terminal users to evaluate the system for training, 
technology transfer, and data processing. This evaluation 
activity was organized through the Earth Observation Division 
of NASA at the Johnson Space Center in Houston, Texas, and 
included participants at five terminal sites and Purdue 
University. In addition to the five sites included in this 
project two other sites were connected to the system under 
separate agreements . The experience of these two sites are 
included in this report. The results of the remote terminal 
project are documented in seven reports: one from each of 

the five project sites, Purdue University, and an overview 
report summarizing the other six reports. This report contains 
the results of Purdue's participation in this project. 
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The purpose of' a remote terminal to the LARS system is 
to provide an earth resources data processing capability to 
any group for training, technology transfer, and data pro- 
cessing. The technology for digital processing of remotely 
sensed data is relatively new. Since the use of this tech- 
nology depends on knowledge of the technology by individuals 
at the site where processing might take place, one of the 
emphases of the remote terminal project was to determine 
appropriate training requirements and provide materials for 
training individuals at the remote site. 

Technology transfer was another major interest of the 
remote terminal project. Trained individuals at a remote 
site does not in itself imply that a capability to process 
earth resources data exists there. A more complete under- 
standing of the technology - including familiarity with 
specific implementations of processing techniques, know- 
ledge of data sources, interdisciplinary approaches to 
information problems, etc. - is required before the capa- 
bility to process data has truly been transferred from a 
group possessing these skills to a group desiring this 
capability. The term "technology transfer" is used in 
this report to denote this broader activity. 

A secondary interest of the remote terminal project 
was determining the extent to which data processing tasks 
could be carried out effectively at a remote site. Once 
the capability to process data has been transferred to the 
remote terminal site, many options are available to the 
site organization for implementation of a hardware/soft- 
ware capability to meet their data processing needs. One 
such option is the continued use of the remote terminal. 

An evaluation of this use has been part of the remote 
terminal project as was the formulation of recommendations 
for future terminal configurations . 

This report documents the details of Purdue's partic- 
ipation in this project. Chapter II describes the history 
of the development of the technology leading to the remote 
terminal concept and the remote terminal project. The 
objectives of the remote terminal project and Purdue's 
participation are also included in Chapter II. A discussion 
of Purdue's activities relating to the remote terminal pro- 
ject is included in Chapter III, organized around the Purdue 
objectives in the project. Much objective and subjective 
data relative to a remote terminal system is contained in 
this chapter. Chapters IV, V, and VI then summarize the 
significant accomplishments, conclusions and recommendations 
resulting from Purdue's participation in the project. 
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II. PROJECT OVERVIEW 


A. Development of LARSYS 

The initial remote sensing data processing research at 
Purdue University began in 1966 Cl, 2 , 3 , 4, 5]. The ob- 
jectives for this research were to develop data processing 
techniques which would apply already-developed pattern rec- 
ognition techniques to remote sensing using multispectral 
scanner data acquired by the Willow Run Laboratory of the 
University of Michigan's Institute of Science and Technology 
[6, 7]. The data processing techniques were (1) to provide 
researchers of all disciplines with access to available multi- 
spectral data; (2) to provide a mechanism by which research- 
ers could merge data from other sources, such as ground 
truth, with the multispectral data; and (3) to provide 
researchers the capability to apply pattern recognition 
techniques to the multispectral data. The purpose of the 
development of these techniques was to establish procedures 
for classifying multispectral data into classes of infor- 
mational value . 

The results of using these procedures in a broad base 
of applications led to the development of an earth resources 
information processing system which can provide, in a timely 
manner, information about the earth's resources. This system 
is called LARSYS (the "LARS System"). Researchers from 
Purdue, NASA, USDA, USDI, the University of Michigan, the 
University of California, and other agencies tested LARSYS 
on many varied applications of remote sensing. The use of 
this system for many applications by these agencies was of 
critical importance to showing the feasibility of using 
machine processing techniques for remote sensing. 

By 1970 the use of LARSYS became limited in two ways. 

One, the system was incapable of being used by researchers 
unless they were physically located at Purdue. Two, the 
system was incapable of handling the number of users willing 
to physically locate themselves at Purdue. However, the 
fundamental concepts of an earth resources data processing 
system had been developed and tested extensively through 
LARSYS. These concepts were the development of a multi- 
spectral - multitemporal data bank, critical hardware and 
software components for the system, and training procedures 
for the use of the system. 

Procedures for the creation of a multispectral - multi- 
temporal data bank were developed for LARSYS . Data from 
most existing multispectral data sources have been made 
available to users of the LARSYS system. In addition, multi- 
temporal data sets were successfully created via registration 
techniques . 
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This relatively rapid access to data through LARSYS was one 
of its most attractive features. 

The concepts of hardware and software required for 
access to the system by researchers of many disciplines 
had also been developed and thoroughly tested. The primary 
access to the system was through a typewriter terminal, a 
printer, a card reader, and a card punch. The concepts of 
interacting with the data via a digital display had also been 
developed and implemented. This ease of access to all aspects 
of the system was another feature which attracted users. 

A problem with using a system like LARSYS , which parti- 
cularly faces universities and in general is shared by all 
other agencies, is one of personnel turnover. The need to 
train users of LARSYS was recognized early in its develop- 
ment; therefore, procedures for this training were developed 
along with the system. Thus, another attractive feature of 
LARSYS was the capability to rapidly train users of the system. 
Training materials and procedures for using them were well 
developed when negotiations began to expand the availability 
of LARSYS to locations remote to Purdue University. 

B. Development of Terminal Concept 

In 1970 when restricted access to LARSYS began to limit 
the research at Purdue and to limit the transfer of the 
technology developed at Purdue to NASA sites and other 
agencies, Dr. A. B. Park began negotiations with Purdue to 
expand the capabilities of LARSYS. The results of these 
negotiations, a remote terminal concept, were documented in 
a letter to Dr. Park by R. B. McDonald of Purdue dated 
February 5, 1970. The concepts included in this documentation 
were expected to significantly speed the development of data 
processing capabilities required for the support of NASA and 
the nation's earth resource program. The concepts presented 
were to tie together the activities of a number of remote 
sensing research groups through a common data processing 
and data communications system. Thus, groups from different 
areas around the country would be able to evaluate the tech- 
niques developed. The remote terminal system would provide 
each group v/ith a Common processing and analysis capability 
and an effective mechanism for exchange of information as it 
becomes available. Each user of the system would have the 
capability of immediate access to analysis techniques, com- 
puter programs, etc. This was felt to be particularly im- 
portant with respect to the availability of data from BRTS . 

The remote terminal system [8] was conceived to be a 
cost effective mechanism of transferring the technology 
developed at Purdue and rapidly exchanging new concepts 
between groups . 
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The cost effectiveness of the system arises from the cen- 
tralization and sharing of the expensive portion of the 
processing hardware, the centralization of software main- 
tenance, and the commonality of system data formats, the 
sharing of common system documentation, the commonality 
of training procedures , etc . 

The remote terminal system began, under NASA spon- 
sorship, with the acquisition of an IBM 360 model 67 
computer system early in 1971. LARSYS was immediately 
implemented on this machine and the development of a 
remote terminal which could be installed at other sites 
began. Also an experiment which thoroughly tested the 
application of the system to a problem of national sig- 
nificance was initiated. 

The 1971 Corn Blight Watch Experiment thoroughly 
tested the technology. The success of this experiment 
to demonstrate that remote sensing technology would solve 
problems of national significance and scope was an important 
milestone in the nation's earth resources program. The 
impact of using LARSYS in the Corn Blight Watch Experi- 
ment was to demonstrate its capability to be used in the 
near operational mode on large amounts of data. By the 
time ERTS was launched, LARSYS had handled ground truth 
data from 240 one by ten mile segments every two weeks, 
classified operationally 4 million data points every two 
weeks, processed the results of the analysis of 270 seg- 
ments (more than 50 thousand agricultural fields) every 
two weeks, in addition to supporting the LARS research 
activity at Purdue. Also a terminal remote to LARS data 
processing facility had been developed, tested, and put 
into operation at Purdue in preparation for training the 
personnel required to support the first terminal remote 
from Purdue University. 

C. Project Objectives 

John D. Overton of the Earth Observations Division, 
Science and Application Directorate, Johnson Space Center, 
Houston, Texas was appointed chairman of the remote terminal 
steering committee. Under his leadership, a committee of 
Terry L. Phillips from Purdue University, William L. Alford 
of the Goddard Space Flight Center, Harold Maurer of the 
Wallops Station, John Cornwell of the Lockheed Electronics 
Corporation, and Frank Ravet of the Earth Resources Program 
Office at the Johnson Space Center, prepared a document 
entitled, "Plan for the Evaluation of Remote Terminals with 
Purdue University's Laboratory for Applications of Remote 
Sensing." This plan was finalized in February of 1973 and 
approved by all participants on the remote terminal steering 
committee . 
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The plan detailed the initial scope of the project 
and a project duration of one year starting January 1973. 

A project implementation plan with appropriate management 
reviews, reports, supporting documentation, and schedule 
is also included in this plan. The steering committee 
methods for accomplishing the project objectives are also 
delineated. All aspects of the remote terminal project 
were coordinated by the steering committee chairman 
through the use of a computer generated project schedule 
showing each project goal. The monitoring of the com- 
pletion of each project goal was successful and greatly 
enhanced each participant's ability to accomplish the 
project objectives in a timely manner. 

The objectives of the remote terminal project delin- 
eated in the project plan were; 

1. Evaluate the current techniques and hardware/soft- 
ware implementation, cost estimates, and training 
requirements for extrapolation to a pilot remote 
sensing data processing and analysis system to 
support inter-organizational, geographically 
separated users . 

2. Determine operational feasibility of an inter- 
organizational data processing/analysis system 
for geographically separated users of remotely 
sensed data. 

3. Quantitatively determine critical data processing/ 
analysis habits of diverse investigators for the 
purpose of establishing improved requirements 

for future sensors and data processing facilities. 

4. Provide training in automatic data processing to 
a larger and more diverse set of remote sensor 
data users . 

5. Transfer of developed remote sensor data pro- 
cessing technology to a more diverse set of 
remote sensor data users . 

6 . Determine requirements for follow-on activity 
(if any) to this project. 

Appended to the project plan are the Site Evaluation 
Plans for each of the participants of the project. 

Although the Goddard and Houston terminals were at- 
tached to the system before January 1973 and the steering 
committee began functioning in November 1972, the official 
duration of the project was specified in the project plan 
as calendar year 1973. By March 1973 it became evident 
that Wallops would not have their remote terminal during 
a significant portion of 1973 and the project objectives 
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could be better met if terminals located at non-Pederal 
agency sites could be implemented. These recommendations 
were made to the Earth Resources Program Office and requests 
for additional terminals were sent out. In June of 1973 
the project duration was extended to include calendar 
year 1974 and a request from the State of Texas and Old 
Dominion University was received and recommended for approval 
by the remote terminal steering committee and approved by 
the Earth Resources Program Office. 

D. Purdue Objectives 

The Purdue/LARS Site Evaluation Plan was presented 
to the steering committee on March 20 , 1973. The scope 
of Purdue's plan was in concert with that of the project. 

The Purdue evaluation plan contained procedures for per- 
forming the experiment, criteria for evaluating progress 
in the experiment, technical reports, and objectives. 

The objectives of Purdue's participation in the project 
were: 

1. To provide a facility for the evaluation, by 
a wider community of users, of remote sensing 
data processing techniques developed at Purdue/ 

LARS. 

2. To provide a facility for training personnel 
in the use of advanced remote sensing data 
processing techniques. 

3 . To provide others the opportunity to evaluate 
the current implementation relative to their 
remote sensing data processing needs. 

4. To provide a facility for immediate access to 
and knowledge of present and future techniques 
(transfer of technology) . 

5. To evaluate the current implementation of those 
(remote sensing data processing) techniques in 
the Purdue/LARS remote terminal system and asso- 
ciated software. 

These objectives are presented in an order different 
than they appear in the project plan in order to better 
organize the discussion of the objectives. The order 
given here is used in section III . 


III. DISCUSSION OF PROJECT OBJECTIVES 


This section discusses the highlights of Purdue's 
activities supporting the remote terminal project. These 
activities are discussed using the framework of the ob- 
jectives presented in section II-B of this report. 

A. Establishment of a Remote Terminal Facility 

Objective 1 of Purdue's participation in the remote 
terminal project was: 

"To provide a facility for the evaluation^ by a 

wider community of users ^ of remote sensing data 

processing techniques developed at Purdue/LARS . " 

To meet this objective/ Purdue aided in the installation 
of the Goddard Terminal,, the Houston Terndnal/ the 
Wallops Terminal/ the Langley/Old Dominion University (ODU) 
Terminal/ the Texas Terminal/ and aided the modification 
of the Wallops and Goddard Terminals. In addition/ Purdue 
helped install a terminal at Indiana State University (ISU) 
and the EROS Data Center (EDC) . Reports on these latter 
two installations are included as supplementary information 
to the experiment even though they were not formally part 
of this project. In addition to the terminal installations/ 
Purdue maintained the central processing site. Aspects of 
this support where they relate directly to the remote ter- 
minal project are also discussed here. A diagram of the 
location of these terminals is shown in figure 1. 

1. Basic Considerations Relative to Terminal Installation: 

a. Terminal hardware. The design of LARSYS provides 
for the user to access and control processing via a key- 
board terminal. A line printer/card- reader/card-punch 
facility is also required at each site for production of 
output/ as well as for reading input decks. For this exper- 
iment/ it was necessairy to use terminals supported by 'the 
operating system of the Purdue 360/67 - namely an IBM 2741 
or teletype 33/35 typewriter terminal/ and an IBM 2780 
reader/printer/punch. Presumably/ "equivalent" hardware 
from other manufacturers would work, but several factors 
mitigated against exploring the possibilities in this area, 
at least at the beginning of the experiment. The most 
important was the fact that the prepared training packages 
for LARSYS users assumed the use of IBM equipment. These 
had been prepared using a remote terminal made up of an 
IBM 2741 typewriter terminal and an IBM 2780 line printer/ 
card-reader/card-punch. This terminal was already success- 
fully in operation at a LARS site half a mile away from the 
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Figure 1. Location of Remote Termin.ils in December 1974 
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main computer site. Also, the IBM sales organization 
offered special support for and assistance in creating a 
network of remote terminals under their "host computer 
concept." Accordingly, it was decided that the initial 
terminals should emulate the prototype as much as possible 
and use the IBM hardware. 

b. Communication lines. Of the several possibilities 
for communications, the simplest in concept is to have a 
separate, leased full-duplex phone line for each terminal -- 
the typewriter and the reader/printer/punch . The prototype 
terminal used this scheme. The possibility of using dial- 
up facilities was explored, but was rejected for this experi- 
ment for a variety of reasons - the most important being 
expected reliability at the high speed (4800 bps) required 
for operation of the 2780 reader/printer/punch. A second 
possibility was that of using a single leased phone line 
instead of two, with appropriate modems including multi- 
plexors . This concept was used for installations after the 
first one. Details such as the conditioning required depend 
on the choice of modems - see below. 

c. Modems. Details concerning modems are determined 
by the type of communications lines to be used, and vice 
versa. The initially recommended modems were the WE203 for 
the 2780, and use of the modems built into the terminal and 
computer hardware for the 2741 line. This combination re- 
quires C2 conditioning on the one phone line and no special 
conditioning on the other. The second arrangement to be tried 
used Codex 7200 modems with secondary channels - the primary 
channel being used for the 2780 and the secondary channel (or 
reverse channel) being used for the 2741. This requires just 
one phone line with C2 conditioning, A later arrangement 
utilized a Paradyne M48 or Codex 4800 modem with reverse 
channel — this combination in principle does not require 

a specially conditioned line. 

d. Software changes to attach new terminals to the 
Purdue computer. It is necessary for the system programming 
staff to modify the computer operating system to define 
appropriate "ports" to accomodate each new terminal that is 
to be attached. LARSYS also must be modified, since it in- 
cludes a feature designed to automatically recognize the 
location of each user ' s typewriter terminal and to automa- 
tically route his output to the 2780 at the corresponding 
site. Other related tasks need to be handled — assignment 
of IDs, passwords, disk space, etc. All these considerations 
were well understood prior to the experiment and caused no 
problems . 
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e. Data. Procedures had to be set up to allow users 
at remote sites to enter data into the LARS data base, and 
to allow tapes containing results of processing to be sent 
back to users at their request. 

2. Goddard Terminal Installation: 

The installation of the initial terminal at Goddard Space 
Plight Center, in August-September of 1972, did not go as 
smoothly as had been hoped. Initially, there were coordi- 
nation problems arising from the fact that NASCOM (located at 
Goddard) ordered the telephone lines and modems and that 
Purdue/LARS ordered the terminal hardware. Delays in the 
installation of the former meant that the terminal hardware 
lay unused for a month, although it was on rent. Then after 
the 2780 finally could be tested online, it would not operate 
properly with the Purdue software system. Even after the 
cause of this problem was pinpointed Can analysis of data 
being received at Purdue showed that the 2780 was sending 
two bytes in the redundancy check character position instead 
of the proper one byte) , it still took nearly a week for 
IBM to find the hardware cause of the problem (a miswired 
connection in the 2780) . 

Some operational problems existed from the beginning 
with the modem configuration used for the Goddard terminal 
(WE203A modems, with a home-built loopback/ test facility) . 

A newer and more modern WE208A replaced the WE203A in May 
1973, and led to somewhat more trouble-free operation. 

3. Houston Terminal Installation; 

The installation of the second terminal, at the NASA 
Manned Spacecraft Center Clater Johnson Space Center) in 
November- December 1972, was accomplished with much less 
trouble. This was all the more gratifying, since it in- 
cluded a previously untried combination of a Codex modem 
and multiplexor at each end of a single telephone line. 

This allowed the single telephone line to be used to run 
both the 2741 and 2780 terminals. John Cornwell at Houston 
did an excellent job of ordering and scheduling installation 
of all components — terminals, modems, phone line. The 
lack of problems demonstrated the value of having a single 
knowledgeable coordinator at a single site throughout pro- 
curement, installation, and production usage. 

A second 2741 terminal was attached, using a new 
circuit board in each Codex multiplexor, during July 1973. 
Finally, after a few preliminary experiments over the dial- 
up network using teletype- ‘ompatible CRT terminals, a third 
low speed port was added to each Codex multiplexor during 
the early part of 1974. 
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4. Wallops Terminal Installation: 

The third remote terminal was installed at the NASA 
Wallops Island Facility in October 1973* This event was 
significant in that a Data 100 Model 70-2 terminal was 
used in place of the IBM 2780 in the "standard” remote 
terminal configuration. This terminal had been success- 
fully demonstrated at Goddard in June 1973. It was also 
of interest because instead of having phone lines installed 
between Wallops and Purdue, NASCOM installed lines betv/een 
Wallops and Goddard. The lines between Goddard and Purdue 
were shared — during some periods they would be used for 
the Goddard terminal, and at other times they would be used 
to "extend" the Wallops lines. While one site was opera- 
tional, the other site would be "off-the-air . " 

This arrangement caused many operational problems since 
it seemed to take a long time for the Goddard and Wallops 
personnel to appreciate all the ramifications. Considerable 
confusion arose when, for example, output files belonging 
to Wallops were printed on the Goddard terminal after the 
phone lines were switched in the middle of the day. It also 
took a long time for the terminal users at Wallops and 
Goddard to coordinate their schedules with the NASCOM 
personnel who did the actual switching and they tended to 
expect the Purdue operations people to do the coordinating. 

The substitution of the "plug-compatible" Data 100 
terminal for the IBM 2780 terminal in the Wallops con- 
figuration produced an interesting example of a "never 
should happen — but will" kind of problem. The card 
punch would not work at all, which turned out to be due 
to the fact that the Data 100 card punch (which is slower 
than the 2780 punch) was too slow to keep pace with the 
rate at which the Purdue software would send data to be 
punched. Then, the Purdue software (in violation of the 
IBM bi-sync protocol) would re-transmit the as-yet un- 
acknowledged buffer instead of sending an inquiry about 
it. 


The problem was circumvented by modifying the Purdue 
software to make it transmit blocks short enough to allow 
even a Data 100 to get a block punched and acknowledged 
before the next one arrives . 

5. Langley Terminal Installation: 

The notable feature about the installation of the 
fourth remote terminal at the NASA Langley Research Center 
in Hampton, Virginia, was that it marked the introduction 
of yet another modem vendor - Paradyne - and yet another 
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communications carrier — Western Union. This installation 
was easily the most troublesome of all. 

The installation was scheduled for January 1974. The 
initial combination of Paradyne modem and Western Union 
telephone line (also ordered by NASCOM) worked so poorly 
that a decision was made to replace the line with a C2 
conditioned line from ATT/ which was installed in April 1974. 
Another problem existed in interfacing the Paradyne modem 
to the IBM 3705 Communications Controller — resulting from 
the fact that IBM was not adhering to the RS-232 standard. 

The 3705 would place extraneous signals on lead 14 of the 
interface, which interfered with the operation of the 2741 
terminal on the secondary channel. This problem was 
permanently resolved by obtaining a fix for the 3705 soft- 
ware from IBM. Finally, in May, 1974, Paradyne discovered 
the clocking pulse was fading out and disappearing every 
so often, and the modem at Langley v?as replaced. 

Towards the middle of June, the IBM 2780 terminal 
developed problems which took IBM a full week to find and 
fix. Then, at the end of July, the 2780 would heat up and 
not operate properly. 

Only since the beginning of September 1974 (after the 
terminals were moved to a new room) , has the Langley 
terminal been able to operate in a relatively trouble- 
free mode. 

6. Texas Terminal Installation: 

The installation of the fifth remote terminal was at 
the state offices in Austin, Texas. This was a notable 
milestone in that this was the first terminal located at 
a non-NASA site. The installation date was also scheduled 
for January, 1974. However, there was a delay in instal- 
lation, due mainly to difficulties encountered in nego- 
tiating a contract between Purdue and Texas. Delivery of the 
Codex 7200 modems was also a month later than requested. No 
previously untried pieces of equipment were ordered for the 
Texas terminal; two Codex 7200 modems, AT&T lines and the 
IBM 2741 and 2780 terminals were used, but this was the 
first installation for which LARS was responsible for order- 
ing all the equipment. When the actual installation took 
place in mid-March 1974, few problems were encountered. 

The phone cable supplied with the modem had to be altered 
slightly, since the active pins were displaced one position, 
and the printer on the IBM 2780 terminal had to be repaired 
by IBM. 
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Since LARSYS requires control card and data card input, 

LARS was also asked to order an IBM 029 keypunch for Texas. 

This should be kept in mind when future proposals are 
written to install new remote terminals, as many places will 
not already have EBCDIC keypunches available for use. 

7. Wallops-Goddard Terminal Modifications: 

In spite of the multitude of difficulties encountered 
with the installation and performance of the Paradyne modem 
system for the Langley terminal, it was decided by NASCOM 
at Goddard (responsible for the Goddard, Wallops, and Langley 
communications links) to proceed with a plan to reconfigure 
the communications links for the Goddard and Wallops termi- 
nals. This plan called for using one of the existing Pur- 
due/Goddard phone lines coupled to one of the existing God- 
dard/Wallops lines , togethier with a set of Paradyne modems 
to give Wallops their own private link to the Purdue sys- 
tem, The remaining Purdue/Goddard line was to be used with 
yet another pair of Paradyhes to serve the Goddard terminal 
(while the second Goddard/Wallops line was neleased) . 

In order to do this, it was also hebessary to coordinate 
the removal (by IBM) of one special feature and the installa- 
tion of a different feature on both the Goddard and Wallops 
2741 Vs, the installation (hardware and software) of corres- 
ponding features on the 3705 at Purdue, and the removal of 
the WE208 modems in use up to that time. All this was 
done in May- June 1974. 

8. Indiana State University Terminal Installation: 

After a two and a half week delay in the shipment of 
the Codex modems, a terminal was installed at Indiana State 
University, Terre Haute, Indiana in September 1974. Both 
Codex and IBM had to be called in to service their equip- 
ment, and the terminal was completely operational by the 
end of September, three weeks after the scheduled date of 
operation. This is the first time the Codex 4800 modems have 
been used, and except for the fact that the use of a small 
connector cable (delivered with the modem) between the 2780 
and the modem was not documented anywhere in our manuals, their 
operation has been completely satisfactory for operating an 
IBM 2780 and one IBM 2741 terminal, at a lesser monthly lease 
rate than the Codex 7200 modems. 

9. EROS Data Center Terminal Installation: 

The most recent terminal, scheduled to be operational 
on October 8, 1974 at the EROS Data Center, Sioux Falls, 

South Dakota, was completely operational by November 1, 

1974. This site has the seime set'-up as the Texas remote 
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terminal - Codex 7200 modems, AT&T lines, and ItJM 2741 and 
2780 terminals^* A slight complicating factor was the need to 
deal with two ?i.oeal telephone companies in addition to AT&T -• 
General Telephone in Lafayette, and a local phone company 
at Garretsen, South Dakota Cjust outside Sioux Falls) . 

The IBM terminals arrived several days later than planned 
due to the distance they had to travel from North Carolina. 
Then a diff icult-to*-diagnose problem, first blamed on the 
phone company, was worked on by Codex for about two and a 
half weeks and was finally solved with the 'replacement of 
several boards in both modems. During the same period IBM 
found and corrected several problems in the 2741 terminal. 

10. Central Processing Site Modifications: 

In the initial phases of the remote terminal experiment, 
the Purdue system had only seven IBM 2400 tape drives. 

This had significant implications related to scheduling 
users, and equitably sharing the scarce resource among users 
at Purdue and at the new remote sites. An initial guideline 
allowed only one remote terminal user; to be active on the 
system at a given time, and guidelines relative to reserving 
time on tape drives were also in use. By January 1973, these 
drives were replaced by seven improved IBM 3420 drives. 
Splitting these between two control units at that time also 
helped significantly. Finally, in February 1973, three 
additional drives were added, significantly reducing schedul- 
ing and availability difficulties. 

In April and May of 1973, an IBM 3705 Communications 
Controller was added to the Purdue computer, replacing the 
2703 Transmission Control Unit. In each case, this is the 
part of the computer that attaches directly to the modems 
and phone lines for all terminals. Although there was some 
deterioration of service during the conversion, this was 
compensated for by the fact that with the advent of the 
3705 it was readily possible and convenient to use its 
dials and switches to monitor activity (or lack of activity) 
on any given port, to tell if data is being sent or received, 
what operation has been issued to the line, what the modem 
status is, etc. This information was found to be useful 
in diagnosing problems. 

The release of LARSYS Version 3, supplementing Version 2 
occurred in July 1973. This is discussed in more detail in 
another section of this report. It has a beneficial effect 
on the problem of tape drive scarcity, since Version 3 makes 
it less easy for any user to keep a tape drive unnecessarily 
long. 
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11. Terminal Installation Costs; 

The experience of coordinating the installation of 
seven remote terminals has allowed the Purdue staff to 
estimate the cost of terminal installation. This estimate 
is ;shown in Table 1. The costs shown in this table are 
based on an objective analysis for the Purdue staff, 
observation for the terminal staff, and specific costs. 

Although the costs of installing any one of the seven 
terminals usually varies from the estimate shown in Table 1, 
it is believed that $15,000 is a good estimate for the 
average installation. Each of the parts of this estimate, 
explained below, also has a relatively high variance. Hov?- 
ever, if a terminal is installed as recommended by Phillips 
and Schwingendorf E9H , the estimate shown in Table 1 should 
be quite adequate. 

The terminal installation costs shown in Table 1 
include administrative staff from both Purdue and the 
terminal organization. This administrative staff is ex- 
pected to negotiate the boundary conditions around which 
the terminal will be installed. The Purdue system specialists 
and the terminal system specialists then combine their efforts 
to prepare the location for the terminal, prepare the Purdue 
system for the terminal, order the necessary equipment, and 
coordinate the installation. The Purdue techniques specialist 
is responsible for the training of the terminal system specia- 
list and terminal techniques specialist. This is usually 
done by the terminal specialists coming to Purdue and parti- 
cipating in a training program of two weeks duration. The 
terminal techniques specialist then is expected to train the 
users of the terminal through the media of the LARSYS 
Education Package and the expertise derived from taking the 
Purdue Training Course. The Purdue service staff and the 
terminal service staff are supportive of the above effort 
with the clerical services, electrical installation services, 
etc. The 30 computer tapes are located at 'the central pro- 
cessing site for all users of the given terminal. The shipping 
charges on equipment are for shipping the equipment unique 
to this terminal from the factory and return. The installa- 
tion charges include electrical equipment, phone line instal- 
lation, etc. The telephone and supplies cover other incidental 
installation, communication, and supplies expenses. The 
travel is assumed to be two trips by the terminal system 
specialist and technique specialist of about 1,000 miles to 
Purdue and one other trip between the site and Purdue, probably 
by the Purdue system specialist to check out the terminal site. 

The terminal installation costs include only those 
expenses associated with installing the system. They do 
not include any costs for using or maintaining the system. 
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Table 1. Terminal Installation Costs 


Purdue Administrative Staff 
Purdue System Specialist 
Purdue Techniques Specialist 
Purdue Service Staff 
Terminal Administrative Staff 
Terminal System Specialist 
Terminal Techniques Specialist 
Terminal Service Staff 
IiAPSYS Educational Package 
Computer Tapes 

Shipping charges and equipment 
Installation charges 
Telephone, supplies 
Travel 


.5 

mm 


$2 , 400/mm 

$1,200 

1.0 

mm 

& 

$1, 800/mm 

1,800 

1.0 

mm 


$1, 800/mm 

1,800 

.5 

mm 

@ 

$1, 000/mm, 

500 

.5 

mm 

@ 

$2 , 400/mm^ 

1,200 

1.0 

mm 

0 

$1 , 800/mm 

1,800 

1.0 

mm 

0 

$1, 800/mm 

1,800 

.5 

mm 

0 

$1 , 000/mm 

500 



0 

$925 each 

925 


30 

0 

$12.00 each 

360 





500 





600 





800 

trips 

0 

$2 00/trip 

600 


$14,385 
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The monthly terminal maintenance costs will be discussed 
in a later subsection. The terminal installation costs can 
be compared to the costs of installing other systems of this 
type such as installing software on a general purpose com- 
puter, installing a specific hardware/software system, etc. 

12. Final System Configuration 

Figure 2 shows the final LARS Computer configuration 
at the end of the remote terminal project in December 1974. 
This configuration consisted of the central processing unit 
and 768k bytes of core, and peripheral equipment including 
a 2314 disk system, the 4507 digital display system, a drum 
system, a tape system, and assorted card readers, card 
punchers, printers and terminals. 

Figure 3 shows the LARS Computer configuration of Decem- 
ber 1974 for the remote terminal hardware. All of the equip- 
ment located at the central site as well as at each of the' 
remote sites, is shown in this figure. 
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B. Peirsonnel Training 

Objective 2 of Purdue's participation in the remote 
terminal project was: 

"To provide a facility for training personnel in 
the use of advanced remote sensing data processing 
techniques . " 

There are four important components which make up the remote 
terminal network - data, hardware, software and training. 

These components compliment one another to bring about the 
successful transfer of the remote sensing technology. The 
facility developed to train personnel in the use of advanced 
remote sensing data processing techniques is composed of two 
types of resources - human resources and training materials 
resources . The human resources consist of the techniques 
specialist and systems specialist site experts. Site experts 
are personnel employed by and located at the organization 
contracting for a remote terminal. These individuals provide 
the important human interface required for a successful 
training program. The training materials resources include 
the LARSYS Education Package, the LARSYS User's Manual, other 
LARSYS documentation, the Purdue/LARS instructors and con- 
sultants . 

1. The LARSYS Education Package: 

In designing the LARSYS Education Package a high priority 
was placed on' making the materials suitable for individual 
study as it was felt that organizations just getting started 
in the analysis of multispectral data would begin by training 
two or three individuals and that because of differing back- 
grounds and other duties might be expected to progress at 
different rates. 

The LARSYS Educational Package consists of a series of six 
minicourses, each designed to take a student from an ini- 
tial point, defined by the prerequisites of the minicourse, 
to an end point defined by its instructional objectives. 

The student progresses in a linear manner through all six 
minicourses, each of which provides a mechanism for infor- 
mation transfer, an opportunity for the student to practice 
or study the skills or ideas presented, and a problem or test 
situation where he can determine whether he has met the 
instructional objectives. 

A wide variety of media is employed in the Educational 
Package, the selection dependent on the nature of the material 
and the objectives of the unit. Media used include a pro- 
grammed text, a slide/tape presentation, a live demonstration, 
operation of a remote terminal, and practice in doing analyses 
through exercises and an extended case study. The aim has 
always been to choose a medium which allows the learner to 
experience the real analysis procedure as fully as possible. 


The first unit/ entitled/ Remote Sensing Analysis: A 

Basic Preparation / follows the format of a programmed text. 

The specific purpose of this unit is to provide a common 
background to students who expect to make use of the li^RSYS 
data analysis software system,, to acquaint them with the basic 
concepts and introduce them to terminology used later on. 

Since students vary in their previous experience with remote 
sensing, in this unit each may plot his own course through the 
90-page book/ reading only those sections containing materials 
unfamiliar to him. Frequent self-tests help him in these de- 
cisions. Typically students spend from one to six hours on 
this unit/ and average about two and a half hours. The 
second module is designed to give the student a quick, one- 
hour overview of the software capabilities of LARSYS and 
an opportunity to follow, step-by-step, through a typical 
analysis. Since the objective of this unit is to help the 
student gain an overall picture, the medium used is an audio 
tape supported by illustrations which are available either 
as slides or in a flip-chart/notebook format. While a stu- 
dent may stop the tape recorder to take notes or to listen 
to any section of the tape again, this medium was selected 
because it tends to encourage students to let the minute 
details go by in favor of gaining a broader perspective. 

The next two minicourses are designed to acquaint the 
student with the data processing hardware available to him 
at the remote site where he is working, and to this end 
the remote terminal is the "medium" used. The student 
working on Unit 3 witnesses a demonstration of the typewriter, 
card reader/punch, and line printer in addition to pre-printed 
student notes. The "hands-on" experience, which is the core 
of the next unit, gives the student a chance to use the ter- 
minal alone. Listening to an audio cassette tape through 
head phones, he does as the tape directs him, obtaining the 
list of instructional objectives by using the card reader 
and continuing this self-guided work for an average of three 
hours. He runs sample LARSYS jobs, transmits data to and 
receives data from the main computer. The audio tape is 
also supported by a detailed set of written notes for the 
student to use and keep for future reference. 

In the final two units of the Education Package, the 
student, now familiar with the underlying concepts of remote 
sensing and with the operation of the remote terminal, can 
begin using the LARSYS processing functions and study the 
analysis method in detail. Unit 5 contains six short exer- 
cises done at the terminal which, when completed, give the 
student more familiarity with both the nature of the data 
being analyzed and the processing functions available through 
LARSYS . 



The last component of the instructional sequence, en- 
titled Guide to Multi spectra:! Scanner Pata ■Analysis , provides 
a detailed description of the analysis process and helps 
students achieve mastery of the eight analysis steps through 
a carefully developed sequence of study ay^d activity. The 
student can read about the theory behind e.\ach step, study 
an example, test his understandincr by doing the exercises, 
and finally carry out the parallel step in a case study analysis 
This last minicourse is by far the most time consuming with 
most students spending 20 to 30 hours on it. 

It is estimated that over 600 students have gone through 
the Education Package. This is based on the figures shown in 
Table 2 . 

The Education Package was revised with the present version 
being issued in October 1973, to coincide with the availability 
of LARSYS Version 3 on the remote terminal network. A 
feature of the new materials was the inclusion of a postage- 
paid evaluation sheet to be filled out by the student upon 
completion of each unit and mailed to LARS. Although the 
response to this evaluation mechanism has not been as great as 
had been hoped for the student comments that have been re- 
ceived have been helpful in evaluating the education materials. 
Information derived from these forms as well as comments by 
site experts are being used to further refine the Education 
Package. 

Significant changes in format are being made in the first 
two units of the Education Package and content changes are 
being made to reflect the software improvements of LARSYS 3.1. 

In addition another case study, utilizing ERTS data, is being 
developed. The area chosen for analysis is part of Monroe 
County, Indiana and includes the city of Bloomington, surround- 
ing agricultural areas, forest areas, and a portion of the 
Monroe Reservoir. 

2. Site expert training: 

Each remote terminal site designates two individuals to 
serve as site experts. Whenever possible one of these indi- 
viduals, designated as the systems specialist, has experience 
in computer systems. The systems specialist is available to 
trainees and users of the remote terminal to help solve 
computer system problems. The techniques specialist is the 
site expert most knowledgeable in LARSYS analysis techniques. 

Prior to the installation of a remote terminal the site 
experts spend two weeks at LARS going through the LARSYS 
Education Package and receiving additional training on the 
hardware and software aspects of the remote terminal network. 

A typical two-week training schedule is given in Table 3. 


Table 2 . Estimate of Students Trained Using LARSYS 
January 1973 through December 1974 


Terminal Site 

Goddard 

Houston 

Wallops 

Langley/ODU 

Texas 

Indiana State 
EROS Data Center 
Purdue/LARS 


Users Trained 
100 
170 ; 

45 

20 

61 

10 

5 

200 


Source of Data 

Estimate, March 1974 Report shows 50 

Memo March 30, 1974 plus 40 LACIE Training 

Final Report Names 37 not including WaFC Personnel 

5 Langley and 15 ODU Personnel December 1974 Report 

Names in Final Report December 1974 

Estimate 

Estimate 

Estimate from Personnel Turnover 


TOTAL 


611 
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Table 3. Typical Site Expert Training Schedule 


Day 1 a.m. 

-Orientation 

-Overview of educational package and planned activities 
-Discuss ID'S/ Passwords and Computer Schedule 
-Unit 1 (Basic preparation, etc.) 

p.m. 

-Unit 2 (LARSYS Software System Overview) 

-Settle on and request ID's 

-Unit 3 (Remote Terminal Demonstration) 

Assignment 

-Complete reading associated with Unit 1 
-Skim LARSYS Users Manual, Section 2 in prepara- 
tion for Unit 4 (Hands-On) 

Day 2 

-Visit to LARS Computer Facility 
-Prepare input cards for Unit 4 (Hands-On) 

-Unit 4 (Hands-On) 

-Read User's Manual, Sections 1 and 2 
-Begin Unit 5 (LARSYS Exercises) 

Assignment 

-LARSYS User's Manual, Sections 3, 4, 5 and organi- 
zation of the rest of the User's Manual 

Day 3 

^-27 80 Hardware Maintenance Demonstration 
-Complete LARSYS Exercises 
-Begin Unit 6 (Case Study) 

Days 4 through 10 

-Complete case study 

-Review Educational Package: Instructor's Notes 

-Introduction to Unsupervised Data Analysis with 
ERTS Data 

Day 7 

-Visit with reformatting group 
Assignment 

-Program abstracts 9033 and 9034 and Purdue 
LARS Computer User ' s Guide 

Day 8 

-Seminar on CP 27 80 virtual machine software 
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While the Education Package materials are designed to 
enable the student to proceed on his own the success of his 
experience depends to a large extent on the availability 
of the site experts to interact with him. The function of 
the site expert is not to plan and preside over formal class- 
room Sessions, but rather to serve as a tutor helping to 
clarify troublesome points for the student and to provide the 
necessary corrective feedback and encouragement to enable 
the student to continue on his own. 

3. LARS Techniques Specialist; 

To provide further assistance to remote terminal site 
experts a LARS employee was designated as the remote terminal 
techniques specialist. This person was contacted by the remote 
terminal techniques specialist regarding LARSYS analysis prob- 
lem experienced by users of the system at the terminal site. 
Provision of a contact person helps to further the success 
of the training facility. 

4. Demonstration Package Concept; 

As part of the EROS Data Center remote terminal contract 
LARS personnel are developing a demonstration package to be 
used in conjunction with the EROS Data Center terminal. The 
demonstration package will include posters and charts ex- 
plaining the remote terminal and showing specific usable 
examples, a short terminal demonstration and handout material 
which can be distributed to EROS Data Center visitors and 
trainees . The EROS Data Center contract extends beyond the 
termination data or the remote terminal experiment so these 
materials are not complete at this time. 

5. Advanced Analysis Seminar/Workshop; 

The LARSYS Advanced Analysis Seminar/Workshop provides 
an opportunity for the LARSYS user to become more intimately 
acquainted with the capabilities of the data analysis algo- 
rithms at his command. The LARSYS Educational Package, study 
of which is a prerequisite for participation in the Advanced 
Analysis Seminar/Workshop, provides background material and 
a basic working knowledge of LARSYS. However, the student 
at this point tends to be distracted by the mechanics of 
using the system and cannot be expected to gain more than 
a superficial impression of the mathematical foundations of 
the multispectral data analysis procedures. Yet without a 
firm grounding in these foundations, he is unlikely to be 
able to bring to bear on his remote sensing problem the full 
power of the LARSYS techniques. In fact, he may in some cases 
even try to use them in inconsistent or conflicting ways 
which could produce misleading results or erroneous con- 
clusions . 


.aaaie:;idK<s«sg)se^ 
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Table 4. Topics for the 
LARSYS Advanced Analysis Seminar/Workshop 

Characterization of Data for Statistical Pattern Recognition 
Discriminant functions 
The multivariate normal distribution 
Cluster Analysis for Subclass Determination 

"Blind Analysis” vs. application of ground data 
Interpretation of the, CLUSTER "QUOTients" 

The cluster grouping table 
Use of SEPARABILITY for cluster grouping 
Latest information on clustering techniques 
Use of Class Weights 

Review of the Bayes Optimal Decision Strategy 
An interpretation of the "equal a priori probabilities" 
Intraclass (inter-cluster) weights 
Interclass weights 

Iterative estimation of class weights 
Relationship to weights in SEPARABILITY 
Unsupervised Analysis Techniques 

Use of CLUSTER for "image enhancement" 

Use of ratios for general cover type determination 
Blending Supervised and Unsupervised Analysis 

Extensive and intensive training sample selection 
Use of MERGESTATISTICS 
Separability Analysis 

Interpretation of results 
Selecting the number of channels 
Mul-titemporal Analysis 

Benefits and potential pitfalls 
Use of SEPARABILITY 
Applications Exercises 

Use of LARSYS techniques on data familiar to the student 


case 
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C. Remote Terminal Facility Support 

Objective 3 of Purdue's participation in the remote 
terminal project was: 

"To provide others the opportunity to evaluate the 
current implementation relative to their remote 
sensing needs." 

It was clear to the developers of the remote terminal 
system at Purdue and to the Remote Terminal Steering Com- 
mittee from the start of the evaluation project that eval- 
uation would not take place unless encouragement and support 
was continually made available to each site. Therefore, 
in addition to providing a facility (objective 1) and 
training resources (objective 2) , Purdue assumed the 
responsibility to provide continued support to key personnel 
at each remote terminal site. The purpose of objective 3 
was to insure user awareness of the availability of services 
and to measure the awareness and the cost effectiveness 
of services to users. 

1. Awareness of services: 

Several procedures were established to insure user 
awareness of the availability of services to a terminal 
site. The most important of these was the establishment 
of the site specialist. Purdue strongly suggested that 
each terminal site designate two people to serve as system 
and techniques specialist who would be available to users. 

The system specialist is responsible for working with his 
counterpart at Purdue/LARS on the installation of the 
terminal and then in sorting out hardware and software 
problems encountered by any user at the terminal site. 

The techniques specialist is responsible for training all 
users of the system at the terminal site and for consulting 
with them on analysis problems. 

These two remote site personnel are required to com- 
plete the two-week LARSYS Analysis for Instructor's Course 
at Purdue to prepare for their duties. Personnel from each 
of the seven sites effectively followed this procedure and 
therefore established an effective communication link be- 
tween the user and the Data Processing Center. The effect 
of the communication link is to respond to the user's needs 
with a minimum effort required by the user. The established 
communication channel was designed to answer any questions 
the user might have even in areas where documented responses 
do not exist. 

The second activity established to insure user awareness 
of the system was the provision of complete documentation 
for the user. This activity was established well before the 
first terminal was installed. However, complete documen- 
tation was not available until after the first two terminals 
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were installed. Therefore, some measure of the usefulness 
of this documentation is available in the user statistics 
of the system. 

A non-documented version of LARSYS was made available 
to the Goddard and Houston terminals at the time of their 
installation. This version of LARSYS was used by these 
two terminals through July, 1973. The fully documented 
version of LARSYS was put on line in July of 1973 and 
user’s manuals were distributed to the two terminal sites. 

A two- day LARSYS refresher course was held at Purdue to 
acquaint the system specialist and the techniques specialist 
from these sites along with personnel from the Wallops site 
to introduce LARSYS Version 3. The completeness of this 
documentation allowed each of the sites to quickly change 
over to using Version 3.0 and gave the users increased confi- 
dence in the system. 

In addition to the documentation of LARSYS, two other 
documents were made available to the terminal sites. One 
was the Computer User's Guide, and the second was a Terminal 
Procedures Manual which was developed as experience between 
the terminal site and the data processing site increased. 

Another major activity established to guarantee the user 
an ability to interface with the system was that of main- 
taining the data library to meet each user's individual needs. 
This activity was the principal subject of the Terminal 
Procedures Manual and a significant portion of Purdue resources 
spent on the remote terminal project were used to insure 
availability of data to the users in a format which met his 
needs. During 1973, one hundred and fifty-eight runs were 
put into the LARSYS library for remote terminal users. 

These runs included ERTS scenes, ERIM aircraft scenes, NASA 
24-channel scanner scenes, digitized photography, specially 
preprocessed (geometrically corrected and registered) scenes, 
and many other reformatted products. By the end of 1973, 
eight hundred runs were available to every user on the remote 
terminal system. This activity became quasi operational in 
1974 and 1300 data scenes were available by the end of that 
year. 

2. Cost Effectiveness; 

There are many references throughout this report alluding 
to the fact that the terminal system is a cost effective 
system. Therefore, it is appropriate to report measures of 
cost and effectiveness of the system. Two of these measures 
will be discussed. 
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Since a terminal on the network in essence duplicates 
the capability of the system installed at Purdue prior to 
the installation of the network, the effectiveness of the 
original system closely compares to the effectiveness of 
any one of the seven terminals. The cost of the system 
installed at Purdue prior to the establishment of the net- 
work was approximately $350,000 annually of which $200,000 
was spent on personnel and $150,000 spent on equipment, 
supplies , and expenses . 

One measure of cost effectiveness for the terminal 
network is that of comparing the cost of a terminal to 
the cost of the system it duplicates . Table 5 shows the 
average cost of supporting a terminal site for one year. 

The costs shown in the table are estimated from the ex- 
perience of supporting the seven terminals. Since the 
effectiveness of the Purdue system and a terminal on the 
network are similar, the cost of both facilities can be 
compared. The terminal costing $63,250 per year is much 
more cost effective than the $350,000 per year facility 
it replaces. This $63,250 terminal can also be compared 
to other hardware/software systems on the market. 

A less effective system could be installed for less 
than the $63,250. A single programmer could probably 
implement the algorithms commonly used in remote sensing 
analysis on a general purpose machine in six to twelve 
months. This implementation probably would not include 
user-oriented input-output routines or other programming 
"frills.” Furthermore, probably only one or two indi- 
viduals who were very familiar with the programs would 
be able to use the algorithms for analysis purposes. The 
personnel cost required to achieve this capability, which 
might be described as a minimum capability, could range 
from $25,000 to $45,000 depending upon the individual 
salary and supervisory and overhead charges. Since this 
level of capability would be highly dependent upon one or 
two individuals, the associated cost is perhaps more properly 
interpreted as an investment in the individual rather than 
in the software. 

Providing convenient access to a larger group of 
analysts, say ten to twelve individuals, would require 
more careful implementation. User-oriented input-output 
formats and careful dociimentation would be recommended. 

It is estimated that this intermediate level .of analysis 
capability would require a personnel investment of $100,000 
or more per year. 
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Table 5 . Annual Terminal Support Costs 


Purdue Administrative Staff .6 mm @ $2, 400/mm $1,440 
Purdue System Specialist .6 mm @ $1, 800/mm 1,080 
Purdue Techniques Specialist .6 mm 0 $1, 800/mm 1,080 
Purdue Service Staff 3.0 mm 0 $1, 000/mm 3,000 
Terminal Administrative Staff 1.0 mm 0 $2, 400/mm 2,400 
Terminal System Specialist 3 ram 0 $1, 800/mm 5,400 
Terminal Techniques Specialist 3 mm 0 $1, 800/mm 5,400 
Terminal Service Staff 6.0 mm 0 $l,000/ram 6,000 
2741 Rental 0 $112 . 50/month 1,350 
2780 Rental 0 $1, 170/month 14,040 
Codex Modem Rental 5,580 
Phone Line Rental (Average of seven sites) 14 „ 880 
Telephone, Supplies 1,000 
Travel 2 trips 0 $300 per trip 600 


TOTAL FACILITY COST 


$63,250 


One might want to consider establishing a "full 
service" remote sensing data analysis capability. Such 
a capability would include at least everything available 
on a LARSYS terminal, such as preprocessing services, 
specialized program adaptations, and in-house training. 

It is estimated that it would take at least two to three 
years to build up such a capability and would require 
building expertise in preprocessing operations, system 
programming capability, and routine service operations. 

One could anticipate a $300,000 to $500,000 investment 
in personnel to achieve a "full service" capability with 
an accompanying $200,000 to $300,000 annual personnel 
budget to support it. 

The second measure of cost effectiveness for the 
terminal network is in the cost of personnel support for 
the network. As seen above, the personnel cost for the 
system installed at Purdue prior to the establishment of 
the network was approximately $200,000. Also, the cost 
of maintaining similar capability via any other alternatives 
is also expected to be approximately $200,000. The personnel 
costs for supporting the entire network for the two years 
of the project has been approximately $300,000 per year. 
Considering that the number of personnel served by the 
network has increased by a factor of approximately six 
and that the number of installations served has increased 
by a factor of eight, an increase of 50 percent for the 
personnel supporting the system is very minimal. It can 
be shown that the increase cost effectiveness of a network 
over separate facilities is primarily in the area of per- 
sonnel. That is, there has been a corresponding increase 
in cost of equipment of approximately five which is approx- 
imately the increase in effectiveness from a hardware stand- 
point. 

3 . System Usage Parameters : 

Table 6 shows the terminal computer use in hours from 
the time the first terminal was installed in August 1972 
through the end of the project December 1974. Other statis- 
tics with regard to computer use are also shown in the table. 
These include the total CPU time used per month during the 
project by the terminals and the average time used per ter- 
minal by month. The average CPU time used for each of the 
terminals is also shown along with the maximum and minimum 
monthly usage figures. 

Tables 7, 8, and 9 show the use of the analysis software 
for six-month periods of the entire network during the remote 
terminal project. Table 7 shows these statistics for the 
six-month period in which most of the terminals were added 
to the network. The information in Table 7 includes the 
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Table 6. Terminal Computer Use August 1972 - December 1974 

Average per 


Goddard 

Houston 

Wallops 

Langley Texas 

ISU 

EDC 

Total 

Terminal 

1972 










August 

1.9 







1.9 

1.9 

September 

.1 







.1 

.1 

October 

.1 







.1 

.1 

November 

.8 

1.4 






2.2 

1.1 

December 

.9 

4.6 






5.5 

2.8 

1973 










January 

.0 

6.7 






6.7 

3.3 

February 

.5 

7.0 






7.5 

3.8 

March 

2.3 

12.5 






14.8 

7.4 

April 

13.2 

9.6 






22.8 

11.4 

May 

27.9 

11.0 






38.9 

19.5 

June 

15.4 

10.2 

.5 





26.1 

8.7 

July 

11.6 

10.6 

1.1 





23.3 

7.8 

August 

34.8 

5.0 

1.6 





41.4 

13.8 

September 

27.3 

2.0 

.1 





29.4 

9.8 

October 

6.5 

2.6 

.2 





9.3 

3.1 

November 

12.4 

4.0 

3.1 

8.8 




28.3 

7.1 

December 

1.2 

4.2 

2.4 

.0 




7.8 

2.0 

1974 










January 

2.0 

6.4 

3.8 

1.3 

.8 



14.3 

2.9 

February 

2.4 

8.3 

1.8 

1.8 

.0 



14.3 

2.9 

March 

4.6 

15.2 

3.7 

1.8 

3.9 



29.2 

5.8 

April 

.9 

16.4 

2.4 

.9 

4.1 



24.7 

4.9 

May 

15.9 

5.9 

1.1 

.6 

4.3 



27.8 

5.6 

June 

1.1 

5.9 

5.4 

.8 

2.9 



16.1 

3.2 

July 

7.1 

7.0 

4.8 

3.3 

10.1 

.3 


32.6 

5.4 

August 

2.6 

19.0 

3.7 

1.4 

4.9 

.3 

.5 

32.4 

4.6 

September 

1. 7 

29.6 

8.6 

1.3 

4.5 

.4 

1.6 

47.7 

6.8 

October 

2.4 

33.1 

.6 

1.1 

4.9 

2.2 

2.4 

46.7 

6.7 

November 

.6 

12.4 

2.9 

4.7 

4.4 

3.1 

. 6 

28.7 

4.1 

December 

.1 

32.8 

1.5 

2.0 

10,5 

1.6 

.2 

48.7 

7.0 

Total 

19 8.3 

2 83.4 

49,3 

29.8 

55.3 

7.9 

5.3 

629.3 

163.6 

Months 

29 

27 

19 

14 

12 

6 

5 

29 

29 

Average 

6.8 

10.5 

2.6 

2.1 

4.6 

1.3 

1.1 

21.7 

5.6 

Maximum 

34.8 

33.1 

8.6 

8.8 

10.5 

3.1 

2.4 

48.7 

19.5 

Minimum 

.0 

1.4 

.1 

.0 

.0 

.3 

.2 

.1 

.1 


reproducibility of the 
ORIGINAL PAGE IS POOR 


Table 7. Network Usage Statistics for 
June 1, 1973 - November 30, 1973 



Times 

Used 

Hours 

Used 

(CPU) 

Computer Usage 

19296 

1371.9 

LARSYS Usage 

9407 

308.4 

Classif /points 

734 

95.9 

Sampleclassify 

24 

.2 

Cluster 

1626 

86.2 

Statistics 

737 

11.2 

Separability 

236 

10.7 

Printresults 

1152 

12.1 

Copyresults 

36 

.5 

Listresults 

52 

1.9 

Punchstatistics 

0 

0.0 

Pictureprint 

1040 

14.8 

Imagedisplay 

1027 

71.3 

Linegraph 

154 

.2 

Columngraph 

194 

.5 

Histogram 

214 

1.9 

Graphhistogram 

49 

.1 

Idprint 

310 

.1 

Duplicaterun 

38 

.1 

Trans ferdc.ta 

54 

.6 

Run table 

1730 

.1 

Data Library Times Accessed 

7098 


Data Library Runs Accessed 

764 
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Table 8. Network Usage Statistics for 
Deceinber 1# 19 73 - May 31, 1974 



Times 

Used 

Hours 

Used 

tCPU) 

Computer Usage 

39160 

1380.1 

LARSYS Usage 

20951 

557.4 

Classifypoints 

1736 

191.1 

Sampleclassify 

164 

23.7 

Cluster 

3453 

132.2 

Statistics 

1405 

21.6 

Separability 

656 

19.9 

Printresults 

2731 

25.7 

Copyresults 

95 

1.4 

Listresults 

98 

2.7 

Punchstatistics 

10 

.1 

Pictureprint 

2108 

37.2 

Imagedisplay 

1424 

94.2 

Linegraph 

290 

1.0 

Columngraph 

406 

1.2 

Histogram 

344 

3.7 

Graphhistogram 

132 

.1 

Idprint 

1141 

.5 

Duplicate run 

133 

.3 

Trans ferdata 

196 

.6 

Run table 

4429 

.2 

Data Library Times Accessed 

9494 


Data Library Runs Accessed 

1038 



Table 9 . Network Usage Statistics for 
June ] i, 1974 “ November 30, 1974 



■ Times 
Used 

Hours 

Used 

(CPU) 

Computer Usage 

25588 

1305.2 

LARSYS Usage 

31619 

655.8 

Class if ypoints 

3119 

267,0 

Sampleclassify 

341 

23.5 

Cluster 

4548 

126.3 

Statistics 

1723 

28.4 

Separability 

1527 

32.9 

Printresults 

5863 

45.5 

Copyresults 

540 

5.8 

Listresults 

386 

12.7 

Punchstatistics 

110 

.6 

Pictureprint 

2458 

35.2 

Iraagedisplay 

1132 

70.0 

Linegraph 

499 

.7 

Columngraph 

538 

1.7 

Histogram 

216 

3.3 

Gr aphhi stogr am 

113 

.1 

Idprint 

744 

.3 

Duplicaterun 

220 

.5 

Trans ferdata 

232 

1.0 

Runtable 

7320 

.3 

Data Library Times Accessed 

9869 


Data Library Runs Accessed 

1007 



number of times the computer was used during this six- 
month period and the CPU hours used. It also includes the 
total number of times LARSYS was used and the number of 
CPU hours involved in this use. The number of times each 
of the 18 processors and the runtable was used is also 
shown with the corresponding hours of CPU times used by 
that processor. Finally the number of times the data 
library was accessed and the mimber of runs accessed in 
the data library was also shown for this six-month period 
of time. 

Tables 8 and 9 then show a more steady-state analysis 
of the terminal system use. It should be noted that the 
computer usage for each of the six months is approximately 
constant. However, the LARSYS usage increased during each 
six-month period. Most of this increase is in the area of 
the CPU time used for Classifypoints. Tables 7 and 8 also 
show that the number of runs accessed and the average number 
of times each run was accessed did not significantly change. 
This indicates strong direction toward classifying larger 
data sets during the last six-month period. These statistics 
are strongly indicative of progress in the ability to train 
a classifier over an area and then classify a larger area. 

It should be noted that the classification processes in- 
creased from 6.9 percent during the first period of the 
total CPU usage to 13.8 percent during the second period 
and finally to 20 percent during the third period. 

All of these usage statistics continue to be available 
from the network. They are considered to be of great 
value to anyone interested in developing similar facilities 
for remote sensing analysis. 
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D, Transfer of Technology 

Objective 4 of Purdue's participation in the remote 
terminal project is: 

"To provide a facility for immediate access to and 

knowledge of present and future techniques (transfer 

of technology) . " 

When the LARSYS remote terminal went on line at Goddard 
Space Flight Center in August 1972, it was the only available 
facility at Goddard for performing LARSYS-type analysis of 
remote sensing data. Since that time the terminal has been 
used for a wide range of purposes, from providing quick 
overviews of the data analysis procedure, to remote sensing 
education, to applications research. It has been observed 
in operation by a wide community, including personnel from 
NASA Headquarters, Wallops Station, Langley, the National 
Bureau of Standards, the Department of Agriculture, three 
universities, three private industrial companies, and many 
others. This exposure and range of users has been fairly 
typical of all of the remote terminals on the LARS network. 
Most notable in virtually every case has been the educational 
use of the remote terminals; the educational process has 
been greatly enhanced by the "hands-on" availability of 
the remote sensing data processing technology. 

As the remote sensing data processing technology has 
continued to evolve, so has the state of the LARSYS software, 
to the benefit of all users concerned. The period of more 
than two years since the initial terminal was installed at 
Goddard has seen considerable upgrade in the LARSYS system. 

The installation of LARSYS Version 3 and associated training 
programs discussed earlier are of significance. Since then 
ten modifications to the system have been made which have 
enhanced the use of LARSYS and 39 software errors have been 
detected and repaired (of these five enhancements and 31 
repairs have effected the remote terminal users, the remainder 
bearing on the digital display system located at LARS) . Some 
of the software errors were found by users at the remote 
sites. These modifications have been realized by 40 separate 
amendments incorporated in the system during the two year 
period. 

Still more substantial upgrades of the system have been 
made on an experimental basis and implemented in an exper- 
imental version of the system. The new techniques so de- 
veloped have been made available on a controlled basis to 
users both at LARS and at the remote sites so that they 
could be evaluated and thoroughly debugged. 


Availability of a common data processing technology 
to so wide a community of users has produced a stimulating 
environment for the interchange of ideas and experiences . 

At one point it was suggested by the Steering Committee that 
a LARSYS users group be formally established so that inter- 
changes of this nature could be further facilitated. It 
turned out that this was not now feasible, primarily because 
of limitations on government travel funds. However, it has 
been possible to maintain the interchange largely by means 
of communication between the site specialists and the rep- 
resentatives to the Steering Committee. 

Also observed has been a "reverse transfer" of tech- 
nology, that is, the inflow of new data processing techniques 
and methodology from the remote sites to the central LARS 
location. For example, a linear combination feature extrac- 
tion capability developed at the University of Houston with 
the support of the Johnson Space Center has been communicated 
to LARS and may be made available to network users after 
appropriate test and evaluation. 

Also made available to the remote site users has been 
the considerable data handling technology developed at LARS, 
particularly in connection with the data from ERTS . This 
has included capabilities for geometric correction, temporal 
overlay, sun angle effect correction, and processing of 
data in the NASA universal imagery format (in which SKYLAB 
data is supplied) . 

Still another use of the technology made available at 
the remote sites has been verification of local implementations 
of the LARSYS algorithms. At the Johnson Space Center, the 
terminal was used to run separability analysis, the results 
of which were compared with the results of a similar pro- 
cessor implemented on-site. 

Of course, there have been difficulties to deal with 
as well. Not long after installation of the first remote 
terminal, it became apparent that the terminal could not be 
used effectively without adequate support from site specialists. 
This had been a premise of the system design and of the for- 
mulation of the LARSYS Educational Package as well; because 
the technology was evolving rapidly, this was necessary to 
smooth transmission of system updates and educational material 
revisions to users at the remote locations. Nonetheless, 
because of the pressure of other responsibilities at the 
remote sites , there was an early tendency to assume that 
new users could get on the system and carry out effective 
analysis with very little attention. This was not the case, 
however, and the result was a very slow start in utilization 
of the remote terminals; despite availability of the hard- 
ware, the data processing technology was not truly available 
until active local support was provided. 
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The greatest apparent problem associated with the 
network has been the trade-off between the costs of 
achieving major update to the LARSYS software system and 
the costs of interchanging techniques without the avail- 
ability of extensive documentation. Major modifications in 
two of the processing algorithms have been used on the sys- 
tem for more than a year without available documentation. 

These modifications have been shared between sites but are 
not available to all users on the system. The time lag 
between the initial availability of technology and complete 
documentation of the technology has been approximately 18 
months. The principle reason for this delay has been the 
time and cost required to update pertinent docvunentation 
and making this documentation available for distribution. 

Of course, this is the first time that such an update has 
been made to LARSYS since the release of Version 3. Some 
of the delay has been the result of the development of 
effective procedures not only for the update of the soft- 
ware but for the documentation revision and dissemination 
as well. Although this is sometimes frustrating to users 
of any system of this type, the effectiveness of the 
procedures established have been close to optimal. Per- 
sonnel who require a faster rate of technology transfer 
can speed the availability of new techniques through special 
procedures and at a higher cost. On the other hand, personnel 
who are not willing to pay the higher cost still participate 
in the knowledge made available at a slower rate. 

E. System Evaluation 

Objective 5 of Purdue's participation in the remote 
terminal project is: 

"To evaluate the current implementation of those 
techniques (remote sensing data processing) in the 
Purdue/LARS remote terminal system and associated 
software." 

Soon after inception of the first remote sensing data 
processing system designs it became apparent that opera- 
tional application of the objective technology implied 
that users of the developed system would be from many 
disciplines having a wide range of technical backgrounds 
which may not include the use of computer systems. Also 
apparent was the requirement for large scale system access 
and data dissemination. Although development of processing 
algorithms, user interface techniques and applications re- 
search have enjoyed a decade of progress, realization of 
large scale system access and data dissemination have only 
undergone conceptual design and initial testing. In this 
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project testing of an approach to providing large scale 
access to state of the art remote sensing data processing 
capabilities was achieved. The approach was access to a 
centralized hardware/software system via remote terminals. 

1. Machine-Data Interface: 

Of jprimary importance when providing access to a pro- 
cessing capability is the analyst-' to- computer and analyst- 
to-data interfaces. To analyze image data the analyst must 
be provided means of interacting with the data and to utilize 
machine processing techniques he must have effective means 
of interacting with the machine and thus the processing 
techniques . 

a. The software interface. Given the criteria that 
an effective remote sensing data processing system must 
have wide and general use and that users would ultimately 
be of diverse backgrounds, not necessarily including the 
use of computers, LARSYS was developed to make the user's 
interaction with the analysis functions as straight-forward 
and easy to learn and remember as possible. Thus, user 
convenience was given first consideration when developing 
user interaction aspects of the system. This method of 
easing the learning and operations burden for users has 
been very beneficial to remote users. The most significant 
effect has been the large number of users who have received 
training on the system and made use of its capabilities. 

With the advent of wide-spread use and reduced cost of 
the alphanumeric cathode ray tube conversational terminals 
additional convenience may be possible by employing the 
menu selection technique for user-system interfacing. This 
method of executing LARSYS can be more effective and con- 
venient depending on the user and application. This method 
would be cost effective for remote sites, since LARSYS could 
be accessed without the use of keypunch, card read, or card 
punch machines. A disadvantage of the method is that the 
user would not have a hardcopy of his execution control 
stream; however, this function could be provided through user 
storage areas in the central system. 

Early in the experiment users voiced a need to generate 
experimental versions of various LARSYS functions. This 
capability was provided when LARSYS Version 3 was placed on 
line in June, 1973. Version 3 is implemented with a modular 
structure, so that users may generate experimental versions 
of only those processor functions of interest. 
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b. The hardware interface. With exception of the 
image interaction digital display device, LARSYS was 
developed around the use of long standard computer peri- 
pheral devices, card reader, card punch, line printer and 
conversational teletypewriter. These devices are available 
in easy-to-use standard configurations and are readily avail- 
able for remote connection to the central facility. 

Prior to the. beginning of the remote terminal experi- 
ment, an IBM 2780 reader/printer/punch remote terminal unit 
was installed at the central facility for development of 
support software. This unit in combination with an IBM 2741 
typewriter make up the basic peripheral equipment needed for 
operating LARSYS. With exception of a Data 100 Corporation 
equivalent of the 2780, this configuration was used at all 
remote sites. This configuration served well ;tn providing 
access to the system and effective use of LARSYS. It became 
apparent, however, to achieve successful general application 
of the remote terminal concept and thus large scale access 
to the remote sensing data processing technology, support 
of a more complex and diverse array of terminal equipment 
would be required. From this realization has grown the 
need for development of the "remote terminal family concept." 
The family concept provides for cost effective access to the 
central facility via a family of terminal configurations. 

The concept is required largely due to the wide range of 
applications for which remote terminals are installed and 
range of usage requirements at various installations. The 
family of equipment selected for system support should allow 
graceful upgrade and degradation, therefore, allowing a 
remote user or user group to not only select a cost effective 
initial terminal configuration, but to modify terminal capa- 
bilities as the application and usage dictates. 

To satisfy the requirements of the family concept, three 
general categories of terminal equipment are needed. The 
level 1 or minimum capability terminal, the level 2 or limited 
capability terminal, and the level 3 or intelligent terminal. 

To allow ease of terminal reconfiguration, each terminal sys- 
tem should be a subset of the largest level 3 system; thus 
repurchase, reinstallation and user reorientation of basic 
components can be avoided when upgrading to larger configura- 
tions. Implementation of this concept will allow more diverse 
application of the remote terminal concept through availability 
of user-application and usage-tailored terminal configurations. 

c. The data interface. From the time the first line 
printer gray scale image was generated the need for a higher 
quality interactive image display was recognized. Line 
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printer images became less effective as remote sensing data 
gathering platforms increased in altitude and ground reso- 
lution elements became larger. A high quality black-and- 
white disk-refreshed cathode ray tube digital interactive 
image display was procured for the LARS central facility 
in 1970. No such image display capability has been provided 
for remote sites which is probably the single most critical 
disadvantage remote users have relative to local LARS users. 
Currently, all remote image displays are provided by the 
PICTUREPRINT processor on line printer output. Although 
line printer images can be effectively used for image inter- 
action, a 10 to 16 gray level cathode ray tube image display 
device could offer analysts significantly extended capa- 
bilities to more accurately and thoroughly analyze gray 
images. The GSFC and Wallops remote site final reports 
state that terminals were not fully utilized because it 
does not have an image display device. 

In addition to providing high quality gray images the 
LARS interactive display provides a machine-aided means of 
selecting and cataloging image coordinates. This on-line 
interaction capability avoids the time consuming, tedious 
task of manually locating, recording, and keypunching image 
coordinates , and eliminates opportunities for introducing 
errors into the analysis. 

To remove this remote terminal handicap, currently 
available interactive image display devices should be 
evaluated and LARSYS support of a suitable device developed. 

It is believed that growth of the remote terminal concept 
for earth resources data processing will be seriously hampered 
without LARSYS support of one or more readily available low 
cost interactive image display devices. 

d. The central facility. The general objective of the 
central computer system and staff is to provide an optimal 
facility for testing concepts and applications of remote 
sensing data processing techniques. As discussed in another 
section of this report, particular attention has gone into 
the LARS computer facility design with respect to providing 
remote access to the system, thus providing a cost effec- 
tive means of exporting the technology. The facility has 
successfully provided: (1) access at remote sites to data 

and a processing capability, (2) sharing of expensive por- 
tions of the processing hardware and of software maintenance, 
and (3) a readily usable system through which users may 
share experiences through standard data formats, terminology, 
and simplicity of communication. 


45 


A primary factor in the overall effectiveness of the 
central facility from the remote users point of view is 
response time. Response time not only with respect to com- 
puter processing speed but to all matters related to remote 
\iser interaction with the facility: machine malfunctions, 

software upgrades and maintenance, special requests, and 
general user inquiries. For the remote terminal experiment 
ample computer resources were available to provide adequate 
machine response, except for brief periods of heavy usage. 
During this experiment several machine upgrades were im- 
plemented as the number of remote and local users increased. 

It is clear, however, that the on-line interactive mode of 
operation requires greater machine resources than batch 
mode, where the system rather than its users can dictate 
the allocation of system resources. 

The concept of site specialists provided efficient 
communications between sites including the central facility. 

By distributing lists designating specialists at each site 
for terminal operations and analysis techniques and coor- 
dinated communication between sites, users were able to 
enjoy reasonably prompt response to questions and problems. 

One capability not provided to remote site users is 
high quality continuous-tone hard copy image output. The 
need for such output is well recognized throughout the 
remote sensing data processing community for imaging of 
both raw data and processing results. Although local users 
may get medium quality low-resolution hard copy displays 
from the LARS cathode ray tube image display, the display 
system is primarily designed for image editing and thus is 
not cost-effective for production hard copy display work. 

Due to the high cost of hard copy image output devices it 
does not seem practical to locate the capability at all data 
processing sites. It is believed that the "sharing of expen- 
sive system components" advantage of the remote terminal con- 
cept itself is directly applicable to the hard copy device; 
that is, the device should be one of the shared components 
at the central facility. Through prescribed procedures, 
remote and local users would specify data for hard copy 
recording, the recording would be made at the central fa- 
cility, and finished products sent to the users. Delivery 
time to remote users should be longer than for local users 
only by the air mail transit time (1 to 3 days) . This method 
of machine utilization is expected to cost-effcctively provide 
a highly needed capability to a large number of users. 

2. Data Base Management: 

For the remote terminal project, remote access to the 
central facility includes access to a large multispectral 
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image storage tape library and extensive data reformatting 
and handling services. Thus, each remote site not only may 
immediately access any of over 1500 data sets but may utilize 
data reformatting services to generate additional data sets 
for the library. Reformatting services frequently used 
include image registration, ERTS rotation and geometric 
correction, Goddard/ERTS-to-LARSYS format conversion, ERIM 
aircraft data-to-LARSYS format conversion, library entry 
of user-generated LARS YS -formatted data sets, and sun angle 
or MARC (mean angle response correction) radiometric correc- 
tion. The user may himself generate LARSYS-formatted data 
tapes to be sent to the central facility for library entry. 

The philosophy implemented, therefore, includes the data base 
and all data preparation as a part of the central facility. 

The basis for this philosophy coincides with the basis of 
the remote terminal concept itself. That is, it provides 
user access and sharing of an expensive portion of the remote 
sensing data processing capability; centralization of re- 
formatting software and operations personnel is achieved; 
and immediate access to implemented reformatting techniques 
is provided at many user sites. 

A large number of reformatting services were provided 
to remote sites. Some problems did arise but were solved 
with communication procedures. By November, 1974, 157 remote 
site user generated LARSYS formatted data sets were entered 
into the LARSYS data base library, 32 Goddard/ERTS data sets 
were converted to LARSYS format, 15 ERIM aircraft data sets 
were digitized and reformatted, 3 MARC corrections made, 

2 ERTS geometric corrections and 2 ERTS image registrations 
were generated. Significant problems in providing reformatting 
services were in the area of procedures and communication. 

At the onset of the terminal experiment a specific procedure 
for transmitting multispectral image data and reformatting 
services requests to LARS had not been prescribed. Difficulty 
in communicating a procedure to many users at several remote 
sites mounted quickly and prompted a procedures docirment. 
Another problem was in messaging users at remote sites that 
requested data had been entered into the library and was 
available for analysis. Users were being informed, but 
often several days after the fact. This problem was solved 
by a procedure in which a message was transmitted to the 
cippropriate remote terminal line printer for posting in the 
terminal area and sending by mail a brief form stating per- 
tinent information to the originator of the reformatting 
request. In most cases following initiation of this pro- 
cedure, line printer messages were transmitted almost im- 
mediately after the requested data set entered the library 
and the forms were mailed on the same day. 
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Even though a central facility serving remote sites 
may have a large existing data library, remote users will 
often be involved in applications projects requiring very 
recent data not yet stored in the central library. In 
addition, many applications require nearly immediate access 
to newly collected data. Ideally the central facility must 
have a means of directly receiving data from primary ground 
data dissemination points by the use of communications links. 
Also, remote sites having data processing capabilities other 
than the LARS terminal may require a terminal feature for 
transmitting large amounts of data to the LARS facility for 
subsequent analysis. This requirement was indicated in the 
JSC, Wallops and GSFC final reports. 


IV. SIGNIFICANT ACCOMPLISHMENTS 


As a result of Purdue's participation in the remote 
terminal project, a number of accomplishments have been 
achieved and are documented in Chapter III of this report. 
These accomplishments are summarized below and are organized 
so that they relate to the objectives of Purdue's part- 
icipation in the project stated in Section II-D. 

A, A remote terminal facility was provided which 
connected seven separate sites to an earth 
resources data processing system located at 
Purdue University in the Laboratory for appli- 
cations of Remote Sensing. Although most of 
these sites experiences some start up diffi- 
culties, only at one site (Langley) were these 
so severe and so extended as to make the instal- 
lation at that site be considered less than 
highly successful. 

B. The basic approach to the development of a 
facility for training personnel in the use of 
advanced data processing techniques for remote 
sensing is sound and has proved itself to be 
effective. The instructional materials designed 
for individual use with a minimum of instructor 
participation meet the needs of most remote ter- 
minal situations and may be adopted for group 
use by an imaginative instructor. Through the 
use of these materials and the remote terminal 
network 600 personnel have been trained in the 
use of the techniques. 


C. A remote terminal has been shown to be a cost 
effective facility for training of personnel, 
transferring technology, and meeting most of 
the current data processing requirements. The 
cost of lesser effective systems to meet similar 
needs has been shown to range between slightly 
less than the cost of a terminal to much greater 
than the cost of a terminal. From the system point 
of view the cost of personnel to support a net- 
work has increased insignificantly with respect 

to services provided when compared to the cost 
of providing separate facilities at each location. 

D. It has been demonstrated that the remote terminal 
approach is an effective way to make available the 
evolving remote sensing data processing technology 
to a wide community of users. As a result of the 
commonality of data processing environment to a 
broad community of users, the interchange of ideas 
and experiences between sites has been facilitated. 
In some cases , a reverse flow of technology has 
occurred .in which new techniques and methodology 
developed at the remote sites are transmitted to 
the central location to be made available across 
the network. 

E. It has been shown that the initial requirements 

of a terminal site are necessary to provide 
training, transfer of technology, and adequate 
data processing services. These requirements 
briefly stated are: 1) access to computer facility 

services which provide a specialized analysis tech- 
nology, 2) a hardware link to these services, 

3) a personnel link between the remote site and 
the central site consisting of a systems specialist 
and a techniques specialist which provide reasonable 
responses to the users needs, 4) a training concept 
including materials, documentation, and instructors 
available to the potential users, 5) an available 
data library and access to data preprocessing 
services. 
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V. CONCLUSIONS 

In addition to the significant accompli shinents listed 
in Chapter IV of this report, a number of conclusions can 
be drawn, based on the material in Section III, which are 
related to Purdue's participation in the remote terminal 
project. 


A. Purdue successfully met each of its objectives 
as listed in Chapter II-D which were established 
at the beginning of the project. 

B. From a systems point of view a reasonable amount 

of latitude is desirable in allowing for "compatible" 
replacements of supported terminal types. Useful 
experience was obtained relative to two vendors 
of terminal equipment (IBM and Data 100) . Similarly, 
useful experience was obtained relative to low speed 
teletype "compatible" cathode ray tube terminals. 

Purdue worked with three vendors of modems (AT&T, 

Codex, and Paradyne) , and two vendors of communications 
lines (AT&T and Western Union) in addition to inter- 
facing with local common carriers. Although a wide 
variety of unexpected problems occurred during these 
experiences, none were insoluble and the ones assoc- 
iated with the terminals were solved quickly. The 
problems associated with the modems and the commu- 
nications lines required the bulk of the attention. 
Therefore, from a systems point of view it seems 
more appropriate to standardize the modem/commu- 
nication lines than the terminals . From a user 
point of view the standardization of terminals 
might be more important as discussed in item C below. 

C. Since most of the terminal installations were com- 
pleted about three weeks behind schedule due to 
delays in delivery and/or malfunctions in the equip- 
ment, it seems reasonable to expect approximately 

a month of start-up operation. For this reason, 
requested delivery dates and system tests should 
be scheduled approximately one month in advance of 
the date when operational use is required. 

D. The remote terminal project has not only established 
a workable education and training procedure but it 
has also shown the need and developed the capability 
to maintain and revise the instructional package 

to reflect the requirements of hardware/software 
changes and the dynamic nature of remote sensing 
technology. This capability was demonstrated in 
the revision of the Educational Package to reflect 
the change from LARSYS Version 2 to LARSYS Version 3 
and in the format changes accompanying the release 
of LARSYS Version 3.1. 
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E . Although the LARSYS Educational Package has been 
demonstrated as a useful tool, experience has shown 
that the package is not sufficient in itself. Key 
components in the training facility are the local 
site experts who are available to administer in- 
struction and provide the vital link between the 
instructional material and student problems and 
questions. These personnel are also key in the 
decision of the standardization of the teirminal 
hardware. If these personnel can effectively 
communicate the changes in the terminal hardware 

to all of the students, then the standardization 
of the terminal hardware is not required. 

F. Although the remote terminal concept has demon- 
strated a highly effective mechanism for trans- 
ferring technology, this approach is maximally 
effective only when adequate support is provided 
at the remote terminal site to compliment the 
physical availability of the hardware and soft- 
ware. This is particularly true for the techniques 
specialist. The absence of a techniques specialist 
at some remote sites seriously effected the transfer 
of technology. 

G. The remote terminal project has demonstrated that 
large scale access to the remote sensing data 
processing techniques can be achieved through 
remote terminal systems. The three key elements 

of the remote terminal system — hardware, software, 
and training — were successfully implemented and 
were used by a multitude of personnel. 

H. In addition to demonstrating both feasibility and 
practicality of the concept, the experiment pro- 
vided a basis for further development of require- 
ments for more effective terminal systems. The 
following hardware requirements were recognized 
and reconfirmed as a result of the experiment. 

In order of their priority these are: 1) a low 

cost interactive image display device supported 

V by LARSYS, 2) a wide range or "family" of terminal 
configurations should be identified and supported 
by the system, 3) a high quality hardcopy display 
capability should be located at the central facility 
for operational use by remote sites, and 4) the 
concept of high voliime communications links between 
the central facility and the primary data dis- 
semination facilities should be developed to 
provide near immediate access to remote sensing 
data by users of the entire network. 
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VI . RECOMMENDATIONS 


Several reconmiendations with respect to future remote 
terminal sites and for follow-on activities have resulted 
from Purdue's participation in the remote terminal project. 
The background for these recommendations are documented in 
Chapter III of this report. 

A. Since the goal of the remote terminal project was 
to demonstrate the feasibility of the approach 

to providing a facility for immediate access to 
and knowledge of present and future techniques, 
this report and the reports from the remote 
terminal sites demonstrate the success of the 
project and the appropriate conclusion at this 
point in time. Hov/ever, the system is continuing 
to evolve and it is clear that we have not yet 
determined the full extent to which this approach 
can be utilized for the effective transfer of new 
data processing technology. It seems in order, 
therefore, to consider continuation of the project 
in order to further probe the extent to which such 
effective transfer is possible. 

B. The remote terminal "family" concept should be 
developed in the areas of terminal system and, 
software support. Attention should be given to 
a minimum capability characterized by dial up 
voice grade communication links, low speed inter- 
active typewriter or cathode ray tube terminals , 
and, optionally, a low speed printer. A second 
capability would include implementation of a 

low cost remote interactive image display device 
with associated software support. This capability 
would include displaying gray-scale images and 
user selection of image element coordinates and 
possibly cassette tape units for control and 
data information exchange. Thirdly, a full 
capability terminal system should be developed. 
This facility would provide a wide range of data 
interaction devices. The software or LARSYS 
support for all of these facilities should be 
designed to support any combination of the 
terminal family. 

C. A high quality hardcopy image display system 
should be implemented at the central processing 
facility for operational access to remote users. 
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D, A communication link between the central pro- 
cessing site and data distribution centers should 
be implemented to speed access to data for users 
of the system. Also, remote terminal equipment 
should be implemented so that data could be ex- 
changed between the remote sites and the data 
processing facility. 

E. To assist the site experts in their roles as 
instructors it is recommended that future remote 
terminal contracts include the support of a LARS 
education and training consultant who would be 
available by the telephone to assist in solving 
individual training problems and to provide a 
direct feedback path to the developers of the 
educational package. The LARS education and 
training consultant should initiate calls to 
remote terminal sites on at least a monthly 
basis if the site experts have not called in 
with specific requests. 

P. To stimulate local interest, remote terminal sites 
should be encouraged to work with LARS personnel 
in the development of a demonstration and/or case 
study geared specifically to a problem of general 
interest to personnel and/or visitors to the re- 
mote terminal location, 

G. Add to the site expert training at LARS two to 
three hours on general aspects of educational 
philosophy and the specific philosophies around 
which the Education Package was designed. 

H. Continue to pursue the concept of a LARSYS user 
group in conjunction with the remote terminal 
network- The full potential for furthering the 
technology by interchange of ideas and experiences 
which would be facilitated by such a users group 
can only be speculated on at this point. Even 
the exchange which has taken place between site 
experts and at long distance users of the system 
has proven most beneficial. 

I . Include in future remote terminal contracts re- 
sources to support a LARSYS advanced analysis 
seminar/workshop. The timing and topics to be 
included in the serainar/workshop should be arranged 
by the remote terminal site and LARS techniques 
specialist. 
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J. LARSYS execution by menu selection techniques 
should be evaluated as an effective user convenience. 

K. The task of coordinating the procurement and installa- 
tion of remote terminals and communications links, 

as well as the responsibility for keeping them oper- 
ational, should be vested in one coordinator located 
at the central computer site. 

L. Where possible standardization of one vendor and 
model of modems is recommended. This would make 
all personnel more effective in troubleshooting 
because of greater familiarity with one type of 
equipment. It would facilitate the development 
and use of standard diagnostic techniques to 
isolate problems and would provide greater possi- 
bility of substitution of one unit for another as 

a diagnostic aid. A greater variety of test equip- 
ment and diagnostic hardware is desirable at the 
central site than was available at Purdue through- 
out this experiment. 

M. A final recommendation which has grown out of the 
experiment and was suggested by the remote terminal 
steering committee is that the LARSYS be further 
modularized in order to facilitate transmission of 
the data processing software to other locations. 
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